On Using Games to Transform Behavior

Today's Art23ac lecture doubled as a CITRIS presentation. I'm not sure what the topic of the talk was supposed to be, but it started off with a vague description of 'service' and 'co-production' that I didn't really buy .

There were two key concepts that stood out from the talk. One was how an image 'performs' for us rather than simply encoding information. Prof. Niemeyer started with an image with flat text data from a weather station for an example of an image with lots of data, but one with a performance that was boring. Then we moved to a line graph of weather data over a time axis. This we could relate to and understand as a trend of global warming. Then there were a series of colored maps and globes, each more eye-catching, but with less data information. The final picture was a cover of 'Gears of War' and a YouTube trailer with flames and fallout in the background. The images that caught my attention and evoked thoughts of heat and evil were the later ones, but really the earlier images were the ones that actually encoded the most information. The warning is to carefully tradeoff between raw dramatic performance and useful information.

The other big concept I really liked is what games can do to transform a person's consciousness. When I walked into the room, I saw a person playing a game with a balance board that looked like a shrunken DDR mat. The board controls a paddle in the center of the screen which can be used to deflect colored balls into correspondingly colored hoops as the hoops revolved around the board. After the player made a few successful shots, the game got harder by making the radius of the circle of hoops smaller, and changing the speed of revolution. Then it would take a while for the player to adjust and make finer grained movements to control the paddle. Besides having an incredibly novel interface, I was amazed by how this system is used by physical therapists for injuries and old people to improve balance. In fact, all the games he later demonstrated had a message and was meant to change the player in some way. One of them wanted to focus on pollution, another on global warming. They all had interesting interfaces and were all intrinsically fun and addictive. The other really cool interface was one that required 3 players to control forward/backward, lateral movement, and altitude respectively. The way a player increased or decreased their control was by making sound into a mic. They'd navigate through a 3d world of some part of human anatomy. There were games for trauma, games for memory loss, and other concepts that were helpful to society.

I thought the talk was great. It gave a good overview of how one can control and manipulate a person's thinking in a indirect way. By using various media combined with an interface that makes the player interact and become part of the game, these games encouraged the player to take a part of that game back with them into their daily lives.

Check out his bio page for links to the games he's collaborated on

On Open Source Software for the Mac

I was looking for a leaner open source word processor to write my history paper in. I came across a great list of common desktop apps, most of which I already use.

The apps I'm interested in using are:

• Bean - Word Processor
• Perian - Addon to Quicktime so it can actually play formats I use.

On Blog Engines

I've been using blog tools on and off for better and for worse. Every time I've tried always ends up somewhere a little past 'bad', but never enough to make me give up. As you can see, the newest contender is Blogger. Let's dig back to see what Blogger's up against.

• EDIT - back when I was on DOS, I kept a mini journal using the EDIT program and floppies for storage. I got bored of writing, and one day my floppy got corrupt.
• Xanga - A high school fad that came and went for most of my friends. I actually wrote in mine, and had a good time with it. When I found out I couldn't get all my posts back without buying a paid account, I was pissed. I used Perl and WWW::Mechanize to scrape back my posts. But it was clunky and I got sick of it.
• LiveJournal - This was supposed to be private, but I never got into it. LJ had a nice clean look. I just lacked the motivation.
• MovableType - This was hosted at OCF, a computing facility at Berkeley. I really liked how I was in control of many options as well as the database containing my actual posts. Then one day my account was disabled because I had some dead sql account password in plain text. This might've worked out, but the OCF was too flaky and poorly maintained, and I would've gave up on them at some point anyways.
• Wordpress, Mephisto, you name it - Movatype drove me to all kinds of other blog systems I would personally maintain. Most of them didn't have more than 2 posts in them before I abandoned them. Plugins were nice, but I missed the days when I just wrote in a text file...
• Markdown + Text - So I went full circle and came back to plain text. Plain text is great. It's portable, easily compressed, and easy manipulated. Combining it with Markdown made it very readable and very web compliant. Everything was looking up until the end of the summer. At that point, I started getting tired of scrolling through the long page of posts, not being able to have comments, and not being able to sort or limit the range of dates for posts. Basically, I wanted to have more feature-ful and robust blog engine again... Just without the DB. I did try Bloxom at some point, and thought it was wonderful, but didn't like how the dates were tied to the last-modified timestamp of the files.

So here I am. I came to Blogger cause my brother just started one. I'm actually excited about this one because of the external ftp publishing option that allows me to store my posts on a server that I control. I also like how it uses flat files. I like the existing user base, and the ability to comment. I like the potential future integration with Google apps. I like how the GreaseMonkey script to edit with Markdown. There's a lot to like, and no downsides other than migrating my existing posts here. This might be the system for me.

Update: Blogger is not even close to XHTML strict. Le sigh.

On Good Advertising

I respect Mercedes so much more after they released a great 11 minute commercial about their SLR.

Of course, there was obligatory sexy Apple gear throughout.

On Tutoring

The last time I tutored someone was in middle school for english. I thought I was helpful and apparently it helped the ki d score higher in some test or other. I also got paid a little, which was not a bad thing. The downside of the whole experience was that it was boring, and I had to be extra polite and tiptoe around the kid and his family the whole time.

Tutoring Emily's been different so far. I feel like I get to actually know her better and I get very excited when she finds the material interesting (it is CS after all). I don't really care that much about the money, but it does buy me a few extra meals during the week. Seeing her work through the same types of mistakes I made is also worth a good laugh. I don't mean that in a bully kind of way, but it's just fun to see the different types of mistakes. I'm also trying to convince her early to believe in the magic of recursion. Gotta start them young :)

On Motivation and Good Data

On Motivation

I'm frustrated. I hate how people get so easily discouraged by startup failure statistics. I hate how people obsess over everything but personal side projects. For once, I'd like to have a friend who is passionate about a project for the sake of it being a cool project; Not for the sake of a grade; Not even for the sake of money.

On the Right Data

It's easy to make the point that data is a new form of currency in this day and age, but not all data are created equal. You could also say that there exists "data in the rough" where the data may exist, but exists in a medium that's useless.

Bernt Wahl had a good example from his prior experience with homegain. His example is neighborhood data for real estate use. Of course, all the data was available in the heads of the realtors, and there were county boundries and census data. But really, that data is only useful in the context of a neighborhood. So they did the grunt work and refined the existing data into a useful form.

On YCombinator Startup Application

YCombinator is a venture capital firm that's received some media attention because of it's focus on startups founded by young people. In their FAQ, their average founder age is 25, but they've funded people much younger.

I found about this last semester shortly after the application was due. I'll be apply for the winter funding round with an idea I came up with a few weeks ago. Hopefully Minh will be on board. Chris already said he might be too busy during January through March. I've started out filling the application but would like to get more feedback about the idea as well as find maybe one or two more founders to apply with us. I'm confident the idea is solid, but I worry about how we'll present the idea.

I asked Jeremy if he had extra time to join us, but it looks unlikely since he's already agreed to do some contract work with another startup. Perhaps another time and another project.

On Premature Software Testing

I've fallen victim to it a few times now and would like to remind myself of the causes and consequences.

Don't get me wrong, I love testing and have attempted/done/failed at it ever since CS61B. I've used standardized test frameworks, hackish quickie frameworks from school, and created my own small frameworks for specific projects. Testing is a good thing.

But there is such a thing as testing too early. My most recent mishap happened during my internship. I finished a tool that I thought did what I want, and fully tested it. Well, the plus side was that it was perfectly tested against what it does, and worked beautifully for all possible inputs. The downside was that the code didn't do what it was supposed to do! I misunderstood my own requirements and coded something wrong. Then instead of having tests that could support me as I refactored, I ended up with an extra set of barriers that kept me constrained to wrong solutions. In other words, I believed in my tests and this slowed down my redesign towards a correct solution.

Another time this happened to me was during cs164 while I was writing an Earley parser. This one cut me deep because the solution just happened to work against the cases I specified in my tests. Then about one week before the due date, I noticed that I misread the original paper and implemented a system with different semantics. All the tests that exercised individual methods were scrapped. In the end, all tests were scrapped :(

I lost many hours on both those mistakes, but I have noticed different cases when I'm more successful. Here are some guidelines I think work well:

When to Start Testing

• start testing when you start coding for real.
• start coding for real after you've read and re-read your spec enough times to recite it backwards. Think of a design, think of how use cases would fare against that design.
• if there are sections of the design that are ambiguous, or if you aren't sure of what tools to use to implement something, explore with quick dummy code and take notes. Don't even bother putting the dummy code in your repo, or actual directory... It'll only tempt you to keep crappy code. Throw the code away, but keep the notes.
• with design doc, and notes from exploring in hand, try writing some real code. If you find yourself rewriting a ton of stuff repeatedly, you didn't design/explore your problem space enough before starting.
• when exploring concepts and designs, it's a good idea to explore what test strategies are appropriate. I say appropriate because there'll always be some gigantic mammoth of a testing framework with more features than your project needs and a configuration and learning curve to match. Sometimes, the framework that's "just right" is one that you glue together.

How to Test

There are plenty of good guides out there on 'what' to test, but I think many of them provide examples that are too trivial and brittle against refactoring.

• when testing data models, focus on getting consistent domains, and lightweight models. If it's hard to test, it might indicate a flaw in your design.
• unit testing is fantastic, but double check that the methods you're testing are actually relevant and useful. A correct method doesn't imply a useful one. Also, instead of tying very strictly with method names, it can be more readable and flexible to describe your test in terms of the action or mutation.
• don't strictly focus on unit testing. Do the functional tests in parallel to expose useless methods and flawed interactions early on. The same applies for integration tests. Also, the sooner you communicate with modules written by other members of your team, the better.

We all knew that testing too late or not testing at all can cause cancer, but there is such a thing as testing too early. It wastes your time, and may restrict you to a suboptimal or incorrect design. Furthermore, testing isn't the same as designing. No amount of random testing will yield a solid design. Rather, an elegant design will naturally encourage you to think about tests, and those tests can then verify your implementation. Testing is like eating your vegetables: it's good for your health in the long run, but eating too much or the wrong kind will give you the runs.